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Beschreibung 

VERFAHREN, SOFTWARE- PRODUKT UND VORRI CHTUNGEN ZUR S IGNAL I S I ERUNG DER MODIFIKATION 

VON BEARERVERB INDUNGEN MITTELS SIP PROTOKOLIi 

5 

In der Vergangenheit haben sich zwei wesentliche Typen von 
Kommunikationsnetzen zur Obermittlung von Inf ormationen her- 
ausgebildet: Paketorientierte (Daten-) Netze und leitungsori- 
entierte (Sprach-) Netze. Im Zuge der Konvergenz dieser bei- 
10 den Netztypen haben sich konvergente (Sprach-Daten-) Netze 
herausgebildet . Durch Zusammenschluss dieser unterschiedli- 
chen Netztypen entstehen hybride Netze, in denender Gegen- 
stand der vorliegenden Erfindung mit besonders schOnen Vor- 
teilen zum Einsatz kommt. 

15 

Leitungsorientierte Netze - auch Sprachnetze oder Telephon- 
netze genannt - sind auf die Obermittlung von in der Fachwelt 
auch als Gesprach, Call oder Session bezeichneten kontinuier- 
lich stromenden (Sprach-) Inf ormationen ausgelegt. Die Ober- 

20 mittlung der Inf ormationen erfolgt hierbei iiblicherweise mit 
hoher Dienstgiite und Sicherheit. Beispielsweise ist fur Spra- 
che eine minimale - z.B. < 200 ms - Verzogerung (Delay) ohne 
Schwankungen der Verzogerungszeit (Delay-Jitter) wichtig, da 
Sprache bei Wiedergabe im Empf angsgerat einen kontinuierli- 

25 chen Inf ormationsf luss erfordert. Ein Inf ormationsverlust 
kann deshalb nicht durch ein nochmaliges Obermitteln der 
nicht tibermittelten Information ausgeglichen werden und fiihrt 
im Empf angsgerat iiblicherweise zu akustisch wahrnehmbaren 
Storungen (z.B. Knacksen, Verzerrung, Echo, Stille) . In der 

30 Fachwelt wird die Obermittlung von Sprache verallgemeinert 

auch als Echtzeit- (Obermittlungs-) Dienst bzw. als 'Realtime- 
Service 1 bezeichnet . 

Paketorientierte Netze - auch Datennetze genannt - sind auf 
35 die Obermittlung von in der Fachwelt auch als 'Datenpaket- 
strome T oder 'Flow 1 bezeichneten Paketstromen ausgelegt. 
Hierbei muss iiblicherweise keine hohe Dienstgiite garantiert 
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2 

werden. Ohne garantierte Dienstgute erfolgt die Obermittlung 
der Datenpaketstrome z.B. mit zeitlich schwankenden Verzd- 
gerungen, da die einzelnen Datenpakete der Datenpaketstrome 
Ublicherweise in der Reihenfolge ihres Netzzugangs ubermit- 
5 telt werden, d.h. die zeitlichen VerzSgerui^gen werden umso 
groJBer, je mehr Pakete von einem Datennetz zu ubermitteln 
sind. In der Fachwelt wird die Obermittlung von Daten deshalb 
auch als Obermittlungsdienst ohne Echtzeitbedingungen bzw. 
als f Non-Realtime-Service 1 bezeichnet . 

10 

Die Pakete unterscheiden sich Ublicherweise je nach Art des 
paketorientierten Netzes. Sie konnen beispielsweise als In- 
ternet, X.25 oder Frame Relay Pakete, aber auch als ATM Zel- 
len ausgebildet sein. Sie werden zuweilen auch als Nachrich- 
15 ten bezeichnet, v. a. dann, wenn eine Nachricht in einem Paket 
Ubermittelt wird. 

Ein bekanntes Datennetz ist das Internet. Dieses wird wegen 
des dort zura Einsatz kommenden Internet Protokolls IP zuwei- 

20 len auch IP Netz genannt, wobei dieser Begriff grundsatzlich 
weit zu verstehen ist und alle Netze umfasst, in denen das IP 
Protokoll eingesetzt wird. Das Internet ist als offenes 
(Weitverkehrs-) Datennetz mit offenen Schnittstellen zur 
Verbindung von (zumeist lokalen und regionalen) Datennetzen 

25 unterschiedlicher Hersteller konzipiert. Es stellt eine vom 
Hersteller unabhangige Transportplattform zur VerfUgung. 

Verbindungen sind Kommunikationsbeziehungen zwischen zumin- 
dest zwei Teilnehmern zum Zweck einer - zumeist gegenseiti- 

30 gen, d.h. bi-direktionalen - Inf ormationsUbermittlung . Der 

die Verbindung initiierende Teilnehmer wird Ublicherweise als 
'A-Teilnehmer 1 bezeichnet. Ein durch eine Verbindung mit 
einem A-Teilnehmer in Verbindung gesetzter Teilnehmer heiJJt 
1 B-Teilnehmer 1 . In einem verbindungslosen Netz reprasentieren 

35 Verbindungen zumindest die auf logisch abstrakter Ebene ein- 
deutige Beziehung zwischen A- und B-Teilnehmer, d.h. entspre- 
chend dieser Sichtweise stellen z.B. die verbindungslosen 
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Flows im Internet logisch abstrahierte Verbindungen dar (z.B. 
A-Teilnehmer = Browser und B-Teilnehmer = Web Server) . In 
einem verbindungsorientierten Netz repr&sentieren Verbindun- 
gen zudem auf physikalischer Ebene eindeutige Wege durch das 
5 Netz, entlang denen die Inf ormationen tibermittelt werden. 

Im Zuge der Konvergenz von Sprach- und Datennetzen werden 
Sprachubermittlungsdienste und zunehmend auch breitbandigere 
Dienste wie z.B. Obermittlung von Bewegtbildinf ormationen 

10 ebenfalls in paketorientierten Netzen realisiert, d.h. die 
Obermittlung der bisher Ublicherweise leitungsorientiert 
Ubermittelten Echtzeitdienste erfolgt in einem konvergenten 
Netz - auch Sprach-Daten-Netz genannt - paketorientiert, d.h. 
in Paketstromen. Diese werden auch Echtzeitpaketstrome ge- 

15 nannt . Die Obermittlung von Sprachinf ormationen uber ein 

paketorientiertes IP Netz wird dabei auch mit 'VoIP 1 (Voice 
over IP) gekennzeichnet . 

In den internationalen Standardisierungsgremien IETF (Inter- 
20 net Engineering Task Force) und ITU (International Telecommu- 
nications Union) mehrere verteilte Architekturen fur Sprach- 
Daten-Netze beschrieben. Allen ist gemeinsam, dass die Call 
Control Ebene und die Resource Control Ebene funktional deut- 
lich voneinander getrennt sind und meist sogar auf unter- 
25 schiedlichen Hardware Plattf ormen realisiert werden. 

Die Call Control Ebene umfasst dabei zumindest einen (optio- 
nalen) Call Controller, dem u.a. folgende Funktionen zugeord- 
net sind: 

30 - Address Translation: Umsetzung von E.164 Telephonnummern 
und anderen Alias Adressen (z.B. Rechnernamen) auf Trans- 
portadressen (z.B. Internetadressen) . 

- Admission Control (optional) : Grundsatzliche Zuiassig- 
keitsprtifung, ob und in welchem Umfang (z.B. VoIP fahige) 

35 Einrichtungen das Kommunikationsnetz nutzen dtlrfen. 

- Bandwidth Control (optional) : Verwaltung von Obermitt- 
lungskapazitaten. 
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- Zone Management: Registrierung von (z.B. VoIP fahigen) 
Einrichtungen und Bereitstellung obiger Funktionen fur al- 
le beim Call Controller registrierten Einrichtungen. 

5 Optional konnen einem Call Controller zudem folgende Funktio- 
nen fallweise zugeordnet werden: 

- Call Control Signaling: Alle Signalisierungsnachrichten 
werden von zumindest einem Call Controller vermittelt, 
d.h. alle Einrichtungen schicken und erhalten Signalisie- 

10 rungsnachrichten nur Uber den Call Controller. Ein direk- 

ter Austausch von Signalisierungsnachrichten zwischen den 
Einrichtungen ist untersagt. 

- Call Authorization: Zulassigkeitsprtif ung ftir eingehende 
und ausgehende Calls. 

15 - Bandwidth Management: Steuerung der zulassigen Anzahl von 
Einrichtungen, die gleichzeitig das Kommunikationsnetz 
nutzen dUrfen. 

- Call Management: Verwaltung einer Liste bestehender Ge- 
sprache, urn z.B. ein Besetzzeichen erzeugen zu konnen, 

20 falls dies von der Einrichtung selbst nicht erzeugt werden 

kann . 

- Alias Address Modification: Rttckgabe einer modif izierten 
Alias Adresse, bspw. mit einer H. 22 5.0 Nachricht ACF (Ad- 
mission Confirmation) . Diese Adresse muss der Endpunkt bei 

25 Verbindungsaufbau verwenden. 

- Dialed Digit Translation: Obersetzung der gewahlten Zif- 
fern in eine E.164 Telephonnummer oder eine Nummer aus ei- 
nem privaten Nummer ierungs schema. 

30 Beispiele fttr Call Controller stellen der von der ITU in der 
H.323 Standard Familie vorgeschlagene 'Gatekeeper 1 oder der 
von der IETF vorgeschlagene T SIP Proxy' dar. Wird ein grofie- 
res Kommunikationsnetz in mehrere Domanen - auch ' Zonen' 
genannt - gegliedert, kann in jeder Dom&ne ein separater Call 

35 Controller vorgesehen werden. Eine Domane kann auch ohne 
einen Call Controller betrieben werden. Sind mehrere Call 
Controller in einer Domane vorgesehen, soli nur ein einziger 
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von diesen aktiviert sein. Ein Call Controller ist aus logi- 
scher Sicht getrennt von den Einrichtungen zu sehen. Physika- 
lisch muss er jedoch nicht in einer separaten Call Controller 
Einrichtung realisiert sein, sondern kann auch in jedem End- 
5 punkt einer Verbindung (beispielsweise ausgebildet als H.323 
oder SIP Endpunkt, Endgerat, Media Gateway, Multipoint 
Control Unit) oder auch einer primer zur programmgesteuerten 
Datenverarbeitung ausgebildeten Einrichtung (beispielsweise: 
Rechner, PC, Server) vorgesehen werden. Auch eine physika- 
10 lisch verteilte Realisierung ist moglich. 

Ein alternatives Beispiel ist ein Media Gateway Controller, 
dem ublicherweise die optionalen Funktionen Call Control 
Signaling and Call Management zugeordnet werden. Weiterhin 
15 ist die Zuordnung einer Funktion Signaling Conversion zur 
Umsetzung unterschiedlicher (Signalisierung-) Protokolle 
denkbar, was z.B. an der Grenze von zwei unterschiedlichen 
Netzen, die zu einem hybriden Netz zusammengeschlossen sind, 
erforderlich sein kann. 

20 

Die Resource Control Ebene umfasst zumindest einen Resource 
Controller, dem u.a. folgende Funktionen zugeordnet sind: 

- Capacity Control: Steuerung des dem Kommunikationsnetz 
durch Paketstrome zugefuhrten Verkehrsvolumens, z.B. durch 

25 Kontrolle der Obermittlungskapazitat einzelner Paketstro- 

me . 

- Policy Activation (optional): ggf. fur einen priorisierten 
Paketstrom Resourcen ini Kommunikationsnetz fttr dessen 0- 
bermittlung reservieren . 

30 - Priority Management (optional) : Prioritatskennzeichen in 
den Paketen entsprechend der Prioritat ihrer Paketstrome 
setzen, kontrollieren und gegebenenf alls korrigieren, 
falls die Pakete bereits mit Prioritaten gekennzeichnet 
sind. 

35 

Der Resource Controller wird auch als 'Policy Decision Point 
(PDP) 1 bezeichnet. Er ist beispielsweise innerhalb von sog. 
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Edge Routern - auch Edge Device, Zugangsknoten Oder bei Zu- 
ordnung zu einem Internet Service Provider (ISP) auch Provi- 
der Edge Router (PER) genannt - realisiert. Diese Edge Router 
konnen auch als Media Gateway zu anderen Netzen ausgebildet 
5 sein, mit denen die Sprach-Daten-Netze verbunden werden. 

Diese Media Gateway sind dann sowohl mit einem Sprach-Daten- 
Netz als mit den anderen Netzen verbunden und dienen intern 
der Umsetzung zwischen den unterschiedlichen (Obermittlungs-) 
Protokollen der verschiedenen Netze. Der Resource Controller 
10 kann auch nur als Proxy ausgebildet sein und Resource Cont- 
roller relevante Inf ormationen an eine separate Einrichtung 
weiterleiten, auf der die relevanten Inf ormationen entspre- 
chend einer Funktion des Resource Controllers bearbeitet 
werden, 

15 

Zur Koordination der beiden Ebenen wird ublicherweise eine 
Mehrzahl von Nachrichten versendet, die lediglich zur Abstim- 
mung der beteiligten Komponenten untereinander , jedoch nicht 
zur Obermittlung der "eigentlichen" Inf ormationen zwischen 

20 den Endger&ten dienen. Diese mit den Nachrichten ubermittel- 
ten Informationen werden ublicherweise als Signalisierungsin- 
formationen, Signalisierungsdaten bzw. schlicht als Signali- 
sierung bezeichnet. Der Begriff ist dabei weit zu verstehen. 
So sind z.B. neben den Signalisierungsnachrichten auch die 

25 Nachrichten gemafi dem RAS Protokoll, die Nachrichten gemaJS 
dem ITU-Standard H.245 zur Steuerung von Nutzkanaien beste- 
hender Gesprache sowie alle weiteren ahnlich ausgebildeten 
Nachrichten umfasst. Das Signalisierungsprotokoll ftir den 
Verbindungsaufbau (Call Setup) und -abbau (Call Release) nach 

30 der ITU ist z.B. im Standard H. 225.0 beschrieben, das nach 

der IETF im RFC2543 ("SIP: Session Initiation Protocol") bzw. 
dessen Oberarbeitungen RFC2543bis0x Oder RFC3261. Die "ei- 
gentlichen Informationen" werden zur Unterscheidung von der 
Signalisierung auch Nutzinformationen, Payload, Medieninfor- 

35 mationen, Mediendaten oder schlicht Medien genannt. Kommuni- 
kationsbeziehungen, die zur Obermittlung- der Signalisierung 
dienen, werden im weiteren auch als Signalisierungsverbindun- 
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gen bezeichnet. Die zur ttbermittlung der Nutzinf onaationen 
eingesetzten Kommunikationsbeziehungen werden z.B. Sprechver- 
bindung, Nutzkanalverbindung oder - vereinfacht - Nutzkanal, 
Bearerchannel Oder schlicht Bearer genannt. In diesem Zusam- 
5 menhang versteht man unter out-of-band bzw. outband die Ober- 
mittlung von Inf ormationen auf einem anderen Weg / Medium als 
den im Kommunikationsnetz zur Ubermittlung von Signalisie- 
rungs- und Nutzinf ormationen vorgesehenen , Insbesondere ist 
hiervon eine lokale Konf iguration von Einrichtungen vor Ort 
10 umfasst, die z.B. mit einer lokalen Steuereinrichtung vorge- 
nommen wird. DemgegenUber werden bei in-band Inf ormationen 
auf dem gleichen Weg / Medium, ggf . logisch getrennt von den 
betrachteten Signalisierungs- und Nutzinf ormationen, tibermit- 
telt. 

15 

Das prinzipielle Zusammenwirken der beiden Ebenen sei am 
Beispiel eines Call Setup zwischen zwei als Teilnehmerendge- 
rate ausgebildeten VoIP Einrichtungen erlautert. Dabei wird 
zunachst von einem homogenen Sprach-Daten-Netz ausgegangen. 

2 0 

Innerhalb oder teilweise auch zeitlich vor dem eigentlichen 
Call Setup laufen bei Einwahl eines Endgerats in das IP-Netz 
(z.B. uber einen Internet Service Provider) die Schritte 
Authentisierung, Autorisierung und (Start des). Accounting ab. 

25 Diese sogenannte T AAA f Funktionalitat wird tiblicherweise 

durch den Zugriff auf eine Subscriber-Datenbank, in der alle 
Nutzer mit ihren Kennungen, Passwortern, Rechten, etc, ge- 
speichert sind, realisiert. Dieser Zugriff ist langsam und 
vergleichsweise komplex. In den heutigen "Best Effort" IP 

30 Netzen findet dieser AAA Vorgang normal erweise einmal wShrend 
des Einwahlens des Nutzers statt. Eine weitere Authentisie- 
rung erfolgt bei Einsatz eines Call Controllers, wenn sich 
das Endgerat beim Call Controller des Internet Service Provi- 
ders registriert. Nach dem ITU-Standard H.323 wird diese 

35 Authentisierung bzw. Registrierung eines Endgerats beim zuge- 
ordneten Gatekeeper gemafJ dem RAS (Registration, Admission, 
Status) Protokoll durchgef tthrt, das im ITU-Standard H. 225.0 
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beschrieben ist. 

Der eigentliche Call Setup beginnt Ublicherweise damit, dass 
in einem ersten Schritt die Endgerate der Teilnehmer ihre 
5 Fahigkeiten (z.B. Liste der unterstUtzten CODEC) austauschen, 
um die benotigten Ressourcen (z.B. Bandbreite) und die gefor- 
derte QoS (z.B. Delay, Jitter) zu bestimmen. Die Endgerate 
sind bei Sprachtelephonie z.B. als IP Telephone Oder VoIP 
Client Software ausgebildet, bei Online-Video kennte eines 
10 der Endgerate ein Content- bzw. Application-Server sein, z.B. 
im Netz des Internet Service Providers (ISP) . 

Der Austausch der Signalisierungsnachrichten erfolgt entweder 
direkt zwischen den Endgeraten oder unter Vermittlung eines 

15 Call Controllers. Hierbei ist bei jedem Call fur jedes Endge- 
rat und fur jede Obertragungsrichtung individuell festgelegt, 
welche Variante zum Einsatz koinmt. Die erste Variante wird in 
der H.323 Terminologie auch als 'Direct Endpoint Call Signal- 
ing 1 und die zweite als 'Gatekeeper Routed Call Signaling' 

20 bezeichnet. Bei Direct Endpoint Call Signaling konnen an 

einen Call Controller ggf . Kopien ausgewahlter Signalisie- 
rungsnachrichten ubermittelt werden, so dass ein Call Cont- 
roller auch bei dieser Variante haufig Kenntnis von den zwi- 
schen den Endgeraten abgestimmten Ressourcen- und QoS- 

25 Anforderungen hat. Diese Anforderungen werden jedoch von ihm 
selbst nicht aktiv beeinflusst oder verifiziert. 

Alternativ kann auch das SIP Protokoll zurn Einsatz kommen, 
und zwar sowohl ftir IP Gerate als auch zwischen Media Gateway 

30 Controllern. Im zweiten Fall wird das SIP Protokoll mit 
SIP_T (SIP for Telephones) bezeichnet, das im Standard 
RFC3372 beschrieben ist. Wenn ein Call mit Hilfe des SIP 
Protokolls aufgebaut wird, so wird zwischen den beiden Seiten 
der Verbindung ublicherweise eine Beschreibung des Bearers 

35 ausgetauscht . Dazu wird das Session Description Protocol 

(SDP) nach dem Standard RFC2327 eingesetzt. Dieser Einsatz 
ist u.a. im Standard RFC3264: "An Offer/Answer Model with the 



WO 2005/020535 



PCT/EP2004/051028 



9 



10 



20 



25 



30 



35 



Session Description Protocol (SDP) " beschrieben. Wichtig sind 
dabei vor allem folgende Bearer Daten: 

- IP Adresse der Bearer Connection 

- RTP/UDP Port der Bearer Connection (je nachdem, ob eine 
Sprach- oder Datenubertragung vorliegt) 

- Codec (s), die fur die Sprach bzw. Datentlbertragung bentitzt 
werden (konnen) 

- Streammode der Bearer Connection 



In einem zweiten, optionalen Schritt kann die derart abge- 
stimmte Ressourcen- und QoS-Anforderung direkt von den Endge- 
raten der Teilnehmer an ihren zugeordneten Resource Control- 
ler ubermittelt werden. Nach Priifung der Ressourcen- und QoS- 
15 Anforderung wird von dem Resource Controller eine Bestatigung 
(oder Ablehnung) an das Endgerat zuruckgeschickt . 



In einem dritten, ebenfalls optionalen Schritt wird im Edge 
Router und gegebenenf alls weiteren Routern im Netz eine Poli- 
cy aktiviert, mit der diese Router prufen und gewahrleisten, 
dass der vom Endgerat verursachte Verkehr innerhalb der Gren- 
zen liegt, die in der Anforderung spezifiziert wurden. Ein 
Beispiel fur einen derartigen Reservierungsmechanismus ist 
RSVP (resource Reservation Protocol) . 

Zusammenfassend kann der Function Split zwischen den beiden 
Ebenen so beschrieben werden, dass der Resource Control Ebene 
lediglich die Funktionen zugeordnet sind, die zur Obermitt- 
lung von Nutzinf ormationen erforderlich sind, wahrend von der 
Call Control Ebene die Intelligenz zur Steuerung der Resource 
Control Ebene umfasst ist. Mit anderen Worten: Die Einrich- 
tungen der Resource Control Ebene besitzen mdglichst keine 
Netzsteuerungsintelligenz und konnen in der Folge wirtschaft- 
lich besonders vorteilhaft auf separaten Hardware Plattformen 
realisiert werden. Dies ist wegen der im Vergleich zu Call 
Control Ebene h6heren Installationszahlen in dieser Ebene ein 
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besonders schoner Vorteil. 

Sowohl in konvergenten Sprach-Daten-Netzen als auch in hybri- 
den Netzen, die z.B. durch einen Zusammenschluss eines kon- 
5 vergenten Sprach-Daten-Netzes mit einem konventionellen lei- 
tungsorientierten Sprachnetz gebildet werden, entstehen bei 
der Ubermittlung von Inf ormationen - insbesondere der in 
EchtzeitpaketstrOmen - neue technische Problemstellungen 
aufgrund der neuen bzw. unterschiedlichen Technologien, die 
10 in den jeweiligen Netztypen zum Einsatz koramen. 

Es ist Aufgabe der Erfindung, zumindest eines dieser Probleme 
zu erkennen und durch Angabe von zumindest einer Losung den 
Stand der Technik zu bereichern. 

15 

Die Erfindung stellt sich die Frage, ob nach dem Aufbau eines 
Calls liber das SIP Protokoll weiterhin alle Features genutzt 
werden konnen, die derzeit aus der Telefonie bekannt sind. 
Bei vielen dieser Features sind dabei Modif ikationen des IP 
20 Bearers notwendig, z.B.: 

- Umschaltung der Sprachverbindung auf Datenubertragung fUr 
Fax- und Modem-Anwendungen 

- Bearer Redirection (z.B. fur die Umleitung der Verbindung 
25 auf ein Announcement) 

- Neuaushandlung des Sprach-/Datencodecs wahrend des Calls 
(Mid Call Codec Negotiation) 

- Call Hold und Call Retrieve 

30 Alle oben genannten Features haben einen neuen Austausch der 
Bearer Beschreibung in Form einer SDP Session zur Folge, die 
in einer SIP/SIPJT :Re-INVITE Meldung bzw. der zugehorigen 
SIP/SIP_T Response transportiert wird. Dabei wird die Ursache 
fur die Bearer Modifikation weder im SIP Protokoll noch in 

35 der SDP Session explizit tibertragen, sondern muss auf der 

empfangenden Seite aus den SDP Daten, mit denen lediglich die 
Bearer Modifikation angezeigt wird, regeneriert werden. Diese 
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Regenerierung ist aber nicht immer eindeutig mSglich. Bei- 
spielsweise kann es in folgenden Fallen Probleitie geben: 

- Wird der Codec einer Sprachverbindung geandert, kann dies 
5 ein Codec Switchover fttr Fax/Modem, ein Switchover auf ei- 

nen neuen Sprachcodec, oder aber auch eine Neuaushandlung 
des Sprachcodecs w&hrend des Calls (Mid Call Codec Negoti- 
ation) sein, 

10 - Werden mehrere Features korabiniert, ist es zuweilen nicht 
mehr moglich, anhand der neu empfangenen SDP Session zu 
ermitteln, welche Features kombiniert wurden. Eine SDP 
Session fur Bearer Redirect sieht beispielsweise genauso 
aus wie eine SDP Session, die fUr gleichzeitiges Call 

15 Retrieve und Bearer Redirect geschickt wird. 

Ohne eindeutige Regenerierung der Ursache kann auf der emp- 
fangenden Seite jedoch keine aussagekraf tige Mitteilung ge- 
troffen werden (z.B. am Display eines Telephons oder auf der 
20 Bedienoberflache eines Software Telephon Clients), welches 

Feature gerade von der sendenden Seite aktiviert worden ist. 

Eine Losung fur diese der Erfindung zugrunde liegende Prob- 
lemsituation ist in den Patentansprtichen angegeben. 

25 

Mit dieser L6sung sind eine Vielzahl von Vorteilen verbunden: 

- Durch Ubermittlung der Ursache der Bearer Modifikation 
wird eine uneingeschr^nkte Nutzung verschiedenster Tele- 

30 phonie Leistungsmerkraale ermoglicht. 

- Das bisherige, zum Teil sehr aufwandige, deduktive Ermit- 
teln der Ursache der Bearer Modifikation anhand der uber- 
mittelten Bearer Modifikation entfallt. 

35 

- Durch die (eindeutige) Angabe der Ursache (n) der Bearer 
Modifikation konnen die von der sendenden Seite aktivier- 
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ten Features auch dann bestimmt und angezeigt werden, wenn 
diese nicht deduktiv aus der Bearer Modif ikation regene- 
rierbar sind. 

5 Weitere vorteilhafte Ausgestaltungen der Erfindung ergeben 
sich aus den unter- oder nebengeordneten Anspriichen. 

Das Interworking zwischen den Protokollen SIP / SIP_T und den 
Protokollen BICC CS2 / ISUP+ (siehe ITU-T Recommendation 

10 Q. 1902.x, Bearer Independent Call Control Protocol CS2) wird 
grundlegend vereinfacht, wenn das Protokollelement als action 
Parameter mit folgenden Werten ausgebildet ist: connect- 
backward, connect- forward, connect- forward-no-notif i cation, 
connect- forward-plus-notification, connect- forward- no notif i- 

15 cation-plus-selected codec, connect forward-plus- 
notification-plus-selected codec, connected, switched, se- 
lected-codec, modif y-codec, successful-codec-modification, 
codec-modification-failure, mid-call-codec-negotiation, mod- 
ify-to-selected-codec-information, mid-call-codec- 

20 negotiation- failure, redirect-backwards-request, redirect- 

forwards-request, redirect-bearer- release-request, redirect- 
bearer-release-proceed, redirect-bearer-release-complete, 
redirect-cut-through-request, redirect-bearer-connected- 
indication, redirect-f ailure, remote-hold, remote-hold-ack, 

25 remote-retrieval, remote-retrieval-ack, weil der action Para- 
meter so problemlos in die BICC CS2 / ISUP+ Inf ormationsele- 
mente "Action Indicator" und "Bearer Redirection Indicators" 
umgesetzt werden kann. 

30 Die Erfindung wird im folgenden anhand von weiteren Ausfiih- 
rungsbeispielen, die auch in den Figuren dargestellt sind, 
erlautert. Dabei zeigt: 

Figur 1 eine Anordnung zur Durchfuhrung des erf indungsgema- 
35 fien Verfahrens mit einem hybriden Koramunikations- 

netz, bestehend aus einem paketorientierten, integ- 
rierten Sprach-Daten-Netz und einem leitungsorien- 
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tierten Sprachnetz, die durch zwischengeschaltete 
Media Gateways und Media Gateway Controller verbun- 
den sind, sowie zwei Endpunkten einer Informations- 
tibermittlung 

5 

Figur 2 ein Ablauf diagramm, in dem eine Ausfuhrung der 
Erfindung exemplarisch aufgezeigt ist 

In Figur 1 ist eine beispielhaf te Anordnung zur Durchftthrung 
10" des erf indungsgemafien Verfahrens dargestellt. Sie umfasst ein 
leitungsorientiertes Netz PSTN und ein Kommunikationsnetz IN, 
das vorzugsweise als integriertes Sprach-Daten-Netz SDN aus- 
gebildet ist. Die beiden Netze PSTN, IN sind zu einem hybri- 
den Netz zusammengeschlossen . Das Netz IN ist vorzugsweise 
15 als ein IP Netz (z.B. das Internet) ausgebildet und umfasst 
als Call Controller einen SIP Proxy SP. 

Der Zusammenschluss des leitungsorientierten Bearers TDM mit 
dem paketorientierten Bearer RTP/RTCP wird durch ein zwi- 

20 schengeschaltetes Media Gateways MG zur Konvertierung zwi- 

schen unterschiedlichen, netzspezif ischen Nutzkanaltechnolo- 
gien RTP/RTCP (Real Time [Control] Protocol) und TDM (Time 
Devision Multiplex) , der Zusammenschluss der Signalisierung 
SS7 des Netzes PSTN mit der Signalisierung SIP des Netzes IN 

25 durch zwischengeschaltete Media Gateway Controller MGC x - 3 zur 
Konvertierung zwischen unterschiedlichen netzspezif ischen 
Signalisierungsprotokollen SIP (Session Initiation Protocol) 
bewirkt. Dabei kommt zwischen den Controllern MGCi und MGC 3 
ein Protokoll BICC CS2 / ISUP+ und zwischen den Controllern 

30 MGC 3 und MGC 2 ein Protokoll SIP_T (SIP for Telephones) zum 
Einsatz . 

Das Gateway MG wird von dem ihm zugeordneten Controller MGC a 
durch ein - vorzugsweise international genormtes - Protokoll, 
35 z.B. MGCP (Media Gateway Control Protocol) oder H.248 gesteu- 
ert. Es ist ttblicherweise als separate Einheit realisiert, 
die auf einer anderen physikalischen Einrichtung / Hardware 
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Piatt form zum Ablauf kommt als die Controller MGC. 

An das Netz PSTN A ist ein Teilnehmer A mit Hilfe eines her- 
kommlichen Telephons T, an das Netz IN ein Teilnehmer B mit 
5 der eines SIP fahigen Telephons - z.B. eines in Software 

realisierten SIP Clients SC - angeschlossen, zwischen denen 
als Bearer eine end-to-end Nutzverbindung TDM, RTP/RTCP ein 
gerichtet ist. 



10 In Figur 2 ist die Abfolge von SIP Nachrichten (l)-(4) zum 
Aufbau eines Bearers zwischen zwei SIP Clients A, B und von 
Nachrichten (5) -(17) zur Modifikation des Bearers durch Wei- 
terleitung des Call von dem SIP Client B zu einem SIP Client 
C dargestellt, in der die Nachrichten (5), (6), (12), (13), 

15 (15) und (16) gemaft einem erf indungsgemSBen SIP Protokoll ausge- 
bildet sind. 



Es sei betont, dass die derart aufgezeigten AusfUhrungen der 
Erfindung trotz ihre teilweise sehr detailgetreuen Darstel- 

20 lung von konkreten Netzszenarien lediglich beispielhaf ter 

Natur und nicht einschrankend zu verstehen sind. Dem Fachmann 
ist klar, dass die Erfindung bei alien denkbaren Netzkonfigu- 
rationen, insbesondere anderen Interworking Szenarien sowie 
weiteren paketorientierten Netzen zum Einsatz kommen kann wie 

25 z.B. Intranet, Extranet, einem lokalen Netz (Local Area Net- 
work - LAN) oder einem, z.B. als Virtuelles Privates Netz 
(VPN) ausgebildeten f irmeninternen Netz (Corporate Network) . 

In dem Ausfuhrungsbeispiel nach Figur 1 werden das SIP Proto- 
30 koll sowie sein Derivat SIP_T in einem komplexen, hybriden 

Netzszenario eingesetzt, bei dem die Netzsignalisierung mehr- 
fach zwischen den Protokollen SIP, SIP_T, BICC CS2 / ISUP+, 
SS7 (ISUP) umgesetzt wird. Dabei wird vom Controller MGC 3 
eine Umsetzung zwischen dem Protokoll BICC CS2 / ISUP4- und 
35 dem erf indungsgemafl zumindest ein Protokollelement - insbe- 
sondere Parameter action - zur Anzeige der Ursache von Modi- 
fikationen des Bearers TDM, RTP/RTCP umfassenden SIP T Proto- 
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koll bewirkt. 

Dazu wird in ausgewahlten SIPJT Nachrichten ira Message Body 
neben ein ISUP MIME Content eine SDP Session ttbertragen (mi- 
5 xed content; siehe RFC2 04 6 "Multipurpose Internet Mail Exten- 
sions (MIME) Part Two: Media Types", und RFC3204 "MIME media 
types for ISUP and QSIG Objects"), in deren SDP Body ein 
"Content-Disposition" Header Field gemaJJ RFC2183 eingebettet 
ist, das jeweils zumindest ein erf indungsgemaBes Protokoll- 

10 element zur ttbermittlung der Ursache(n) einer Bearer Modifi- 
kation umfasst. Der "disposition-type" dieses Header Field 
wird auf "session" gesetzt. Zudem wird als neues Protokoll- 
element ein neuer "disposition-parameter" namens "action" zur 
Angabe der Ursache der Bearer Modifikation eingeftthrt und in 

15 das "Content-Disposition" Header Field eingebettet. 

Zur Kombination mehrerer Ursachen/ Features konnen mehrere 
"action" parameter in einem "Content-Disposition" Header 
Field Ubertragen werden. In Anlehnung an die ITU_T Standard 

20 Q.765.5 (Signalling System No . 7 - Application transport 

mechanism for Bearer Independent Call Control), welcher gemafi 
dem ITU-T Standard Q, 1902 .x BICC CS2 (bearer independent call 
control - capability set 2) z.B. zwischen Call Controllern 
MGC zum Einsatz kommt, umfasst der Wertebereich des "action" 

25 parameters folgende Werte: connect-backward, connect-forward, 
connect- forward- no-notification, connect- f orward-plus- 
notif ication, connect-forward-no notification-plus- selected 
codec, connect forward-plus-notification-plus-selected codec, 
connected, switched, selected-codec, modif y-codec, success- 

30 ful-codec-modif ication, codec-modification- failure, mid-call- 
codec-negotiation, modify- to-selected-codec-information, mid- 
call-codec-negotiation- failure, redirect-backwards-request, 
redirect-forwards-request, redirect-bearer-release-request, 
redirect-bearer-release-proceed, redirect-bearer-release- 

35 complete, redirect-cut- through-request, redirect-bearer- 

connected-indication, redirect- failure, remote-hold, remote- 
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hold-ack, remote-retrieval, remote-retr ieval-ack • 



Ein beispielhaf tes erf inching sgemaJJes "Content-Disposition" 
Header Field sieht sieht in diesem Beispiel wie folgt aus 
5 (das erfindungsgemafie Protokollelement ist durch Fettdruck 
hervorgehoben) : 



10 



Content-Disposition: session 

; action=remote-retrieval 

ac t i on=r edi r e c t - f or wa r ds - reques t 



Wegen der Erfindung ergibt sich der schSne Vorteil, dass die 
BICC CS2 / ISUP+ Informationselemente "Action Indicator" und 
"Bearer Redirection Indicators" sehr einfach mit aussagekraf- 
15 tigen Werten befullt werden konnen. 



Als weiteres Ausf Uhrungsbeispiel der Erfindung wird ein Bea- 
rer Modifikation zwischen drei Teilnehmern A, B, C, die alle 
als SIP Clients SC ausgebildet sein, beschrieben. Der Ablauf 
20 dieses Szenarios ist in Figur 2 dargestellt. Zum vereinfach- 
ten Verst^ndnis der Erfindung sind in Figur 2 nur SIP Clients 
SC dargestellt und SIP Proxy Server SP weggelassen. 



Bei diesem Beispiel wird zunachst eine Verbindung/Call zwi- 
25 schen den SIP Clients A und B aufgebaut - Nachrichten (1)- 
(4) . Anschliefiend legt der SIP Client B den Call auf Hold - 
Nachrichten (5) -(7) - und ruft dann den SIP Client C an - 
Nachrichten (8)- (11). Nach diesem Anruf schickt der SIP 
Client B eine "Re-INVITE" Nachricht (12) zum SIP Client A, 
30 mit der er gleichzeitig das Call Hold aufhebt (Call Retrieve) 
und den von dem SIP Client A ausgehenden Call Stream auf den 
SIP Client C (Bearer Redirect) umlenkt - Nachrichten (12)- 
(14) . Schliefilich schickt der SIP Client B eine "Re-INVITE" 
Nachricht (15) zum SIP Client C, mit der er den von dem SIP 
35 Client C ausgehenden Call Stream auf SIP Client A (Bearer 

Redirect) umgelenkt wird. Das Endergebnis ist ein Call Trans- 
fer vom SIP Client B zum SIP Client C. Der SIP Client A kann 
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nun mit dem SIP Client C sprechen. 

Nachfolgend werden die Nachrichten (1)-(17) dargestellt, 
wobei in diesen auf die Darstellung von "Via" Header Fields 
5 verzichtet wird, weil diese filr den SDP Body Content der SIP 
Nachrichten transparent sind. Dabei wird eine SDP Session in 
einer SIP Message als MIME Message Body gemafi RFC2045 trans- 
portiert. Im Falle von SDP wird in diesem Beispiel der Con- 
tent des SIP Message Body mit folgenden SIP Header Fields 
10 spezifiziert: 

- "MIME -Version" : 

fest auf "MIME-Version: 1.0" gesetzt (= RFC2045) - kann 
optional auch weggelassen werden. 

15 

"Content-Length" : 

spezifiziert die Lange des gesamten Message Body. 

- "Content-Type" : 

20 spezifiziert den Typ des Contents in Form eines Media Type 

und Media Subtype. Im Falle von SDP sieht der Content Type 
folgendermaften aus: 



25 



media type - * application" 
media subtype = *SDP" 
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Eine beispielhaf te Nachricht SIP : Re- INVITE mit SDP sieht 
demnach wie f olgt aus : 



10 



15 



20 



INVITE sip: "E.164 (B-Tln) " @ " IP— Addr ( B— Tin) " ; user=phone 
SIP/2.0 

From: <sip : "E .164 (A-Tln) " @ " IP-Addr (A-Tln) " ; user=phone> 
To: <sip:"E.164 (B-Tln) "@" IP-Addr (B-Tln) ";user=phone> 
Call-ID: a84b4c76e66710 
CSeq: 8348 INVITE 

Contact : <sip: "E.164 (A-Tln) "@" IP-Addr (A-Tln) " ;user=phone> 

MIME -Version : 1.0 
Content-Type : application/SDP 
Content-Length : 166 

v=0 

o=hiQ9200 2890844526 2890844527 IN IP4 " IP-Addr (A-Tln) " 
s= 

c=IN IP4 aaa.bb.cc.dd 
t=0 0 

m=audio 2673 RTP/AVP 4 
a=rtpmap:4 G723/8000 
a=sendrecv 



35 



25 Zur ttbertragung der Ursache einer Bearer Modifikation wird 

fur SDP beispielsweise das "Content-Disposition" Header Field 
gemaft RFC2183 eingesetzt, dessen Syntax derjenigen des vorhe- 
rigen Ausfuhrungsbeispiels entsprechen kann. 

30 Eine beispielhaf tes "Content-Disposition" Header Field, das 
wegen einer Bearer Redirection gesendet wird, sieht demnach 
in obiger Nachricht SIP : Re- INVITE, eingebettet in ein SDP 
Protokoll, wie folgt aus (das erf indungsgemaBe Protokollele- 
ment ist durch Fettdruck hervorgehoben) : 



40 



[MIME- Vers ion: 1.0] 
Content-Type : application/SDP 
Content -Disposition: session 

; action=redirect-forwards -request 
Content-Length : xxx 



FQr das Ausftthrungsbeispiel 
Nachr ichten ( 1 ) - ( 17 ) , wobei 
elemente in den Nachrichten 



ergeben sich demnach folgende 
die erf indungsgemafien Protokoll- 
(5), (6), (12), (13), (15) und 
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(16) entsprechend hervorgehoben sind: 

Nachricht (1); INVITE Client A -> Client B 
INVITE sip: ClientB@gmx.com SIP/2.0 
5 From; sip : ClientA@munichnet . com; tag=lc24 841 
To : sip:ClientB@gmx.com 
Call-ID: call-973574144@munichnet.com 
CSeq: 1 INVITE 

Contact : <sip : ClientA@pc4 3 . munichnet . com> 
10 Content-Type: application/sdp 
Content-Length: 161 

v=0 

o=ClientA 2890844526 2890844526 IN IP4 pc43.munichnet.com 
15 s= 

c=IN IP4 192.0.2.101 
t=0 0 

m=audio 49172 RTP/AVP 8 4 
a=r tpmap : 8 PCMA/ 8000 
20 a=rtpmap:4 G723/8000 

Nachricht (2) : 180 Ringing Client B -> Client A 
SIP/2.0 180 Ringing 

From: sip : ClientA@munichnet .com; tag=lc24 8 41 
25 To: sip:ClientB@gmx.com;tag=0da40dd4-81553525 
Call-ID: call-97 3574144@munichnet.com 
CSeq: 1 INVITE 

Contact : <sip : ClientB@sv7 1 . gmx . com> 
Content-Length: 0 

30 

Nachricht (3) : 200 OK Client B -> Client A 
SIP/2.0 200 OK 

From: s ip : ClientA@munichnet . com; tag=lc24 8 4 1 
To : sip : ClientB@gmx . com; tag=0da4 0dd4-81553525 
35 Call-ID: call-97357414 4@munichnet.com 
CSeq: 1 INVITE 

Contact : <sip : ClientB@sv7 1 . gmx . com> 
Content-Type: application/sdp 
Content -Length : 124 

40 

v=0 

o=ClientB 4770 4770 IN IP4 sv71.gmx.com 
s= 

c=IN IP4 178.224.67.133 
45 t=0 0 

m=audio 3456 RTP/AVP 8 
a=rtpmap:8 PCMU/8000 
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Nachricht (4): ACK Client A -> Client B 
ACK sip: ClientB@sv71 .gmx.com SIP/2.0 
From : sip: ClientA@munichne t . com; t ag= 1 c2 4 8 4 1 
To : sip : ClientB@gmx . com; tag=0da40dd4-81553525 
5 Call-ID: call-973574144@munichnet.com 
CSeq: 1 ACK 
Content-Length: 0 

Nachricht (5) : Re- INVITE Client B -> Client A 
10 INVITE sip: ClientA@pc43.munichnet.com SIP/2.0 

From: sip : ClientB@gmx . com; tag=0da4 0dd4- 8 1553525 

To : sip : ClientA@munichnet . com; tag=lc2484 1 

Call-ID: call-973574144@munichnet.com 

CSeq: 2 INVITE 
15 Contact: <sip: ClientB@sv71 . gmx . com> 

Content-Type: application/sdp 

Content-Disposition : session ; 
action=remote-hold 

Content-Length : 128 

20 

v=0 

o=ClientB 4770 4771 IN IP4 sv71.gmx.com 
s= 

c=IN IP4 0.0.0.0 
25 t=0 0 

a—sendonly 

m=audio 3456 RTP/AVP 8 
a=rtpmap: 8 PCMU/8000 

30 Nachricht (6) : 200 OK Client A -> Client B 
SIP/2.0 200 OK 

From: sip : ClientB@gmx . com; tag=0da4 0dd4-81553525 

To : sip : ClientA@munichnet . com; tag=lc24841 

Call-ID: call-973574144@munichnet.com 
35 CSeq: 2 INVITE 

Contact : <sip : ClientA@pc4 3 . munichnet . com> 

Content-Type : application/sdp 

Content-Disposition : session; 

action— remote-hold-ack 
4 0 Content-Length: 155 

v=0 

o=ClientA 2890844526 2890844527 IN IP4 pc43.munichnet.com 
s= 

45 c=IN IP4 0.0.0.0 
t=0 0 

a=recvonly 

m=audio 4 9172 RTP/AVP 8 
a=rtpmap:8 PCMA/8000 
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Nachricht (7) : ACK Client B -> Client A 
ACK sip :ClientA@pc43 •munichnet.com SIP/2.0 
From: sip: ClientB@gmx . com; tag=0da40dd4-81553525 
To : sip : ClientA@munichnet . com; tag=lc24841 
5 Call-ID: call-973574144@munichnet.com 
CSeq: 2 ACK 
Content-Length: 0 

Nachricht (8) : INVITE Client B -> Client C 

10 INVITE sip: ClientC@tomnet.de SIP/2.0 

From: sip:ClientB@gmx.com;tag=0da4 0dd4-81553526 

To: sip: ClientC@tomnet.de 

Call- ID: call-6789@gmx.com 

CSeq: 10 INVITE 
15 Contact: <sip : ClientB@sv71 . gmx. com> 

Content-Type : application/sdp 

Content-Length: 122 

v=0 

20 o=ClientB 5612 5612 IN IP4 sv71.gmx.com 
s= 

c=IN IP4 178.224.67.133 
t-0 0 

m=audio 34 60 RTP/AVP 8 
25 a=rtpmap:8 PCMU/8000 

Nachricht (9) : 180 Ringing Client C -> Client B 

SIP/2.0 180 Ringing 

From: sip:ClientB@gmx.com;tag=0da4 0dd4-8155352 6 
30 To: sip: ClientC@tomnet.de; tag=6545b243a 
Call- ID: call-67 89@gmx.com 
CSeq: 10 INVITE 

Contact : <sip : CI ientC@nb2 3 . tomnet . de> 
Content-Length : 0 

35 

Nachricht (10) : 200 OK Client C -> Client B 
SIP/2.0 200 OK 

From: sip : ClientB@gmx . com; tag=0da4 0dd4-8155352 6 
To : sip : ClientC@ tomnet . de; tag=6545b243a 
40 Call-ID: call-6789@gmx.com 
CSeq: 10 INVITE 

Contact : <sip : ClientC@nb23 . tomnet . de> 
Content-Type : application/sdp 
Content-Length: 127 

45 

v=0 

o-ClientC 293845 293845 IN IP4 nb23.tomnet.de 
s= 

C=IN IP4 27.159.111.76 
50 t=0 0 

m=audio 8275 RTP/AVP 8 
a=rtpmap: 8 PCMU/8000 



WO 2005/020535 



PCT/EP2004/051028 



22 

Nachricht (11) : ACK Client B -> Client C 
ACK sip: ClientC@tomnet.de SIP/2.0 
From: sip : ClientB@gmx . com; tag=0da4 0dd4-8155352 6 
To: sip:ClientC@tonmet.de;tag=6545b2 43a 
5 Call-ID: call~67 89@gmx.com 
CSeq: 10 ACK 
Content-Length: 0 

Nachricht (12) : Re- INVITE Client B -> Client A 
10 INVITE sip: ClientA@pc43.munichnet.com SIP/2.0 

From: sip: ClientB@gmx. com; tag=0da4 0dd4-8 1553525 

To: s ip : C 1 i en t A@mun i chne t . com ;tag=lc24841 

Call-ID: call-973574144@munichnet.com 

CSeq: 3 INVITE 
15 Contact: <sip : ClientB@sv7 1 . gmx . com> 

Content-Type: application/sdp 

Content-Disposition: session; 

action=remote-retrieval ; 
action=redirect-forwards -request 
20 Content-Length: 134 

v=0 

o=ClientB 4770 4772 IN IP4 sv71.gmx.com 
s= 

25 c=IN IP4 27.159.111.76 
t-0 0 

a=sendrecv 

m=audio 827 5 RTP/AVP 8 
a=r tpmap : 8 PCMU/ 8000 

30 

Nachricht (13) : 200 OK Client A -> Client B 

SIP/2.0 200 OK 

From: sip : ClientB@gmx . com; tag=0da4 0dd4-81553525 
To : sip : ClientA@munichnet . com; tag=lc24841 
35 Call-ID: call-973574144@munichnet.com 
CSeq: 3 INVITE 

Contact : <sip : ClientA@pc43 .munichnet . com> 
Content-Type: application/sdp 
Content-Disposition: session; 
4 0 action=remote-retrieval -ack ; 

action=redirect-bearer-connected-indi cation 
Content-Length : 172 

v=0 

45 o-ClientA 2890844526 2890844528 IN IP4 pc43.munichnet.com 
s= 

c=IN IP4 192.0.2.101 
t=0 0 

a=sendrecv 
50 m=audio 4 9172 RTP/AVP 8 
a=r tpmap : 8 PCMA/ 8 000 
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Nachricht (14) : ACK Client B -> Client A 
ACK sip :ClientA@pc4 3 .munichnet.com SIP/2.0 
From: sip:ClientB@gmx. com; tag=0da40dd4-81553525 
To : sip : ClientA@munichnet . com; tag=lc24841 
5 Call-ID: call-973574144@munichnet.com 
CSeq: 3 ACK 
Content-Length: 0 

Nachricht (15) : Re -INVITE Client B -> Client C 
10 INVITE sip: ClientC@nb23.tomnet.de SIP/2.0 

From: sip : ClientBSgmx. com; tag=0da4 0dd4-8 155352 6 

To : sip : ClientC@tomnet . de 

Call-ID: call-67 89@gmx.com 

CSeq: 11 INVITE 
15 Contact: <sip:ClientB@sv71 .gmx.com> 

Content-Type : application/sdp 

Content-Disposition : session ; 

action=redirect-forwards-request 
Content-Length: 120 

20 

v=0 

o=ClientB 5612 5613 IN IP4 sv71.gmx.com 
s= 

c=IN IP4 192.0.2.101 
25 t=0 0 

m=audio 4 9172 RTP/AVP 8 
a=rtpmap:8 PCMU/8000 

Nachricht (16) : 200 OK Client C -> Client B 
30 SIP/2.0 200 OK 

From: sip : ClientB@gmx . com; tag=0da4 0dd4-81553526 

To : sip : ClientC@tomnet . de ; tag=6545b243a 

Call- ID: call-67 89@gmx.com 

CSeq: 11 INVITE 
35 Contact : <sip : ClientC@nb23 . tomnet . de> 

Content-Type : application/sdp 

Content-Disposition: session; 

action=redirect-bearer-connected-indication 
Content-Length : 127 

40 

v=0 

o=ClientC 293845 293846 IN IP4 nb23.tomnet.de 
s= 

C=IN IP4 27.159.111.76 
45 t=0 0 

m=audio 8275 RTP/AVP 8 
a=rtpmap:8 PCMU/8000 
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Nachricht (17) : ACK Client B -> Client C 
ACK sip: ClientC@nb23.tomnet.de SIP/2.0 
From: sip : ClientB@gmx . com; tag=0da40dd4-8155352 6 
To : sip : ClientC@tomnet . de; tag=6545b2 43a 
5 Call-ID: call-67 89@gmx.com 
CSeq: 11 ACK 
Content-Length: 0 

Dem Fachmann ist klar, dass die Erfindung selbstverstandlich 
10 nicht nur in den beschriebenen Szenarien, sondern universell 
in alien Szenarien eingesetzt werden kann, in denen das SIP 
oder SIP_T Protokoll verwendet wird. Insbesondere ist ein 
Einsatz in folgenden Szenarien denkbar: 

15 - VoIP Trunking Subscriber <-> VoIP Trunking Subscriber mit 
dem Protokoll SIP_T zur Signalisierung zwischen Control- 
lern MGC 

- SIP Client <-> VoIP Trunking Subscriber 

- SIP Client <-> Access Gateway 
20 - SIP Client <-> H.323 Subscriber 

- SIP Client <-> VoDSL Subscriber (angeschlossen liber ein 
Integrated Access Device IAD bzw. ein Customer Premises 
Gateway CPG) 

- SIP Client <-> SIP Client 

25 

Abschliefiend sei darauf hingewiesen, dass die Beschreibung 
der far die Erfindung relevanten Komponenten des Kommunikati- 
onsnetzes grundsatzlich nicht einschrankend zu verstehen ist. 
Fur einen einschlagigen Fachmann ist insbesondere offensicht- 

30 lich, dass Begriffe wie Applikation, Client, Server, Gateway, 
Controller, etc. . . funktional und nicht physikalisch zu ver- 
stehen sind. Somit konnen beispielsweise die Endpunkte A, B 
auch teilweise oder vollstandig in Software / Computerpro- 
grammprodukten P und/oder liber mehrere physikalische Einrich- 

35 tungen verteilt realisiert werden. 
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Patentanspruche 

1. SIP Protokoll, 

5 umfassend zumindest ein Protokollelement zur Anzeige der 
Ursache(n) einer Bearer Modi fikat ion. 

2. SIP Protokoll nach Anspruch 1, 

bei dem das Protokollelement in ein Content-Disposition Hea- 
10 der Field gemafi dem Standard RFC2183 eingebettet ist. 

3. SIP Protokoll nach einem der vorstehenden Anspruche, 
bei dem das Protokollelement in ein SDP Protokoll nach dem 
Standard RFC2327 eingebettet ist. 

15 

4. SIP Protokoll nach einem der vorstehenden Anspruche, 

bei dem das Protokollelement als Parameter (action) ausgebil- 
det ist, der mehrfach vorgesehen sein kann. 

20 5. SIP Protokoll nach dem vorstehenden Anspruch, 

bei dem der Wertebereich des Parameters zumindest einen der 
folgenden Werte aufweist: connect-backward, connect-forward, 
connect-forward-no-notification, connect- forward-plus- 
notification, connect- forward-no notification-plus-selected 

25 codec, connect forward-plus-notification-plus-selected codec, 
connected, switched, selected-codec, modif y-codec, success- 
ful-codec-modification, codec-modification- failure, mid-call- 
codec-negotiation, modify-to-selected-codec-information, mid- 
call-codec-negotiation-failure, redirect-backwards-request, 

30 redirect-forwards-request, redirect-bearer-release-request, 
redirect-bearer-release-proceed, redirect-bearer-release- 
complete, redirect-cut-through-request, redirect-bearer- 
connected-indication, redirect-f ailure, remote-hold, remote- 
hold-ack, remote-retrieval, remote-retrieval-ack. 
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6. SIP Protokoll nach einem der vorstehenden Ansprtlche, 
bei dem das SIP Protokoll nach einem der Standards RFC2543, 
RFC3261 Oder RFC3372 ausgebildet 1st. 

5 7. Verfahren zu Modif ikation eines Bearers in einem Kommuni- 
kationsnetz, bei dem die Ursache der Bearer Modifikation mit 
einem Protokoll nach einem der vorstehenden Protokollanspru- 
che signalisiert wird - insbesondere mit Protokollelementen, 
die im gemaB dem Standard RFC2045 ausgebildeten MIME Message 
10 Body von SIP Messages vorgesehen sind. 

8. Computerprogrammprodukt (P) - insbesondere SIP Client 
Software (SC) -, umfassend Softwarecodeabschnitte, mit denen 
ein Verfahren nach dem vorstehenden Verf ahrensanspruch durch 

15 zumindest einen Prozessor ausgefilhrt wird. 

9. Vorrichtung - insbesondere Controller (MGC) , SIP Telephon 
Oder SIP Proxy (SP) -, umfassend Mittel zur Durchftlhrung 
eines Verfahrens nach dem vorstehenden Verf ahrensanspruch . 



20 



10. Anordnung - insbesondere paketorientiertes Netz (IN), 
integriertes Sprach-Daten-Netz (SDN) oder hybrides Netz (IN, 
PSTN) umfassend Computerprogrammprodukte und/oder Vorrich- 
tungen zur Durchfuhrung eines Verfahrens nach dem vorstehen- 
25 den Verf ahrensanspruch . 



